Just my two cents worth.... As Tom basically said, the enormous flexibility the C programmability provides is the KFlops greatest strength, and the fact that you MUST do some C-coding to get even pretty basic functionality working is it's greatest weakness. It's a fabulous product, and quite unique, but it's also quite challenging to bring up. Many potential customers would simply never be able to get the system up and running, beyond perhaps getting basic axis motion, as they would be lost in the C programming. It's OK for the hard stuff to be hard, but the easy stuff MUST be easy, and there's no reason it can't be!

It seems to me this is not fundamentally difficult to overcome for 95+% of users, by providing a few different standardized methods, and just a bit more hand-holding. Looking at how Mach3 handles configuration, and what functionality it provides as standard gives a pretty good model of what functionality is really important. Mach3, right out of the box, meets the needs of probably 98% of its users, with very little fuss. The other 2% (the PITA crowd, like me), are generally smart enough to figure out a way to do the less common functions, and usually make them available to others through the forums.

If it were up to me, I would do the following:

1) First, improve the documentation, particularly the organization. There's a lot of information there, but it's hard to find what you need, when you need it, and a lot of it is out-of-date (for example, the list of available C functions is missing many, like Jog()). A simple overview of the system, and how it functions would be hugely helpful. (witness how much trouble I've had understanding how to just make the machine move and stop programmatically!)
2) Add an "init writer" to KMotion. The current export of individual single-axis C init codes to the clipboard is OK, but it would take so little to just extend it so it writes a complete, working init.c file, it seems silly not to do it. It would seem wise to me to include in this a dialog for setting pin configurations, and writing a header file that defines them all, so they can be used by all user programs.
3) Add **a few**, well documented, standardized methods for doing homing, limits, and probing. These would, ideally, be auto-generated, based on input from the user, through a dialog, which specifies which axes, what pins, speeds, sequence of operations, etc. These don't need to be exhaustive, and don't need to cover every conceivable configuration - just the basics would be fine. I would think all of this could be "built-into" the init function, and be triggered by writing command words into persist registers.
4) Clean up and document the examples, to clarify the means of providing more complex functionality. There's a lot of duplication in there, and some "cruft" that just confuses us newbies, and the core functionality of some of the examples is really not documented, so that some of them raise almost as many questions than they answer. And the use of hard-coded I/O #s and persist registers makes them really hard to read and understand.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Fair enough.
>
>
>
> I can live without most of those items, it was more of a ‘wish list’.
>
>
>
>
>
> The one thing that would be huge is homing, as right now a C program is required to home an axis.
>
>
>
> Can you provide some sort of functionality for basic homing that does not require this?
>
>
>
> For complex scenarios a C program can be used and is great but it would nice to do basic edge/index homing.
>
>
>
>
>
> It is for selfish reasons I ask this(it makes it so MM can handle everything), but I have to imagine it would be useful to many people.
>
>
>
>
>
>
>
> Thank you,
>
>
>
> Brad Murry
>
>
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Friday, November 25, 2011 12:41 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: Mcodes from python
>
>
>
>
>
> Hi Brad,
>
>
>
> Yeah I'm not sure. I'm not saying something like that is not needed but I see some problems. One is that we will be forever having to be in the loop adding new feature requests :} Another is that many of those commands appear to be blocking which would hang all the communication. And if they were made non-blocking they would need an extra cpu thread or extra time in the servo sample code to continuously service them which might make other things less predictable and deterministic.
>
>
>
> Regards
>
> TK
>
>
>
> From: Brad Murry <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, November 25, 2011 10:04 AM
> Subject: RE: [DynoMotion] Re: Mcodes from python
>
>
>
> Asked for a little too much eh?
>
>
>
> Maybe I can write a home routine writing engine.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Brad Murry
> Sent: Thursday, November 24, 2011 9:39 AM
> To: DynoMotion@yahoogroups.com
> Subject: RE: [DynoMotion] Re: Mcodes from python
>
>
>
>
>
> WOW Tom, thanks for the input.
>
>
>
> When I suggested KMotionDLL to be added to, I did not mean to use triggering or any other deterministic functions. I was thinking as you said to have some built in functionality(perhaps exposed as script commands) that are also accessible via KMotionDLL.
>
>
>
> My initial thoughts were that it would be cool to have a master program/mini API (like jquery is for web dev), but I now think it would be cleaner if it existed outside the user program space.
>
>
>
> Probing, homing and watchdog would be good modules to have available, I think I can handle the rest of your list on the PC side and I already am configuring axes via my GUI/ backed by XML files.
>
>
>
> If there were a “Master Program” whether as a user program or in conjunction with embedded functions, I was thinking it should be designed to be nearly invisible to the end user. Set some persistent data via some c++ calls, or public members in the .net classes for example.
>
>
>
>
>
>
>
>
>
> Python is not my favorite language, I use it only because of the IronPython implementation of it sits atop the DLR, which makes all my .net objects accessible. It’s really close to magic the things you can do dynamically without recompiling source. It just makes for a super flexible application because the GUI stuff can be configured at runtime as well as machine behavior.
>
>
>
> That said, it is a very human readable language and my technicians can even tweak things without my help. Many video games have this architecture where the heavy lifting(rendering, etc..) is performed by c++ class libraries and things like character behavior are programed in python by higher level developers.
>
>
>
> I do plan to integrate the Iron JS as soon as it is stable so there are options for scripting in MM. Java Script is closer to C and is a proper ‘braced’ language.
>
>
>
>
>
>
>
> So, as a mechanism to facilitate these “core functions” whether by wizards or from a master program can I request some features?
>
>
>
> 1) Homing
>
>
>
> Something like _Controller.WriteLine(“HOME<Axis Channel> <Switch BIT> <High/Low> <TYPE>”); would be amazing
>
>
>
> Homing speed/accel would be nice as additional axis channel members like you already have with MaxVel, etc…
>
>
>
> TYPE would be negative/positive direction plus the switch logic- (rising falling edge, move to next nearest count, etc…)
>
>
>
> 2) Polling
>
>
>
> _Controller.WriteLine(“POLL<BIT><STATE><TIMEOUT>”);
>
>
>
> 3) IO Pulsing
>
>
>
> _Controller.WriteLine(“PULSEBIT<BIT><INITIAL STATE><DURATION><PULSES>”);
>
>
>
> 4) Triggering
>
>
>
> _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><USER THREAD TO EXECUTE>”);
>
>
>
> _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT><STATE>”);
>
>
>
> _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2>”);
>
>
>
> _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2><BIT3><STATE3>”);
>
>
>
> 5) IO Debounce
>
>
>
> _Controller.WriteLine(“DEBOUNCEBIT<BIT>”);
>
>
>
> 6) Recorder
>
>
>
> _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT>”);
>
>
>
> _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT>”);
>
>
>
> _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2>”);
>
>
>
> _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2>”);
>
>
>
> _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2><BIT3>”);
>
>
>
> _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2><BIT3>”);
>
>
>
> Then
>
>
>
> _Controller.WriteLine(“RECORDSTOP<AXIS CHANNEL>”);
>
>
>
> Values could be stored in an array to processed after recording.
>
>
>
>
>
> Ok, so that is quite a request, but I think with the existing script commands and these we would provide all the building blocks needed to rapidly
>
> configure a machine with or without user programs.(plus add some additional functionality not necessarily related to configuration but would be great to have).
>
>
>
>
>
> What is involved in exposing functionality such as this via script commands?
>
>
>
> Thank you for your time,
>
> Brad Murry
>
>
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Thursday, November 24, 2011 4:52 AM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: Mcodes from python
>
>
>
>
>
> Hi Brad,
>
>
>
> I'm not sure I understand what you mean. As I'm sure you realize anything real time must be performed in the external controller as Windows/The App/KMotionDLL will always have indeterminate response. Windows will be responsive 99.9% of the time but in some very rare cases it will unexpectedly freeze just at the wrong time for a few seconds. I'm fine with that wasting a few seconds now and then, but obviously if it results in missing an index pulse and loading the wrong tool or crashing an axis into the hard stop that is unacceptable. So a "trigger" or interrupt back to the PC doesn't help in those cases. I suppose what you mean is that we could build canned or core functionality into KFLOP to do special operations such as "Stop axis X on Input Bit #N change of Polarity Direction P and signal when complete". So then complex sequences could be programmed on the PC side safely.
>
>
>
> I don't know what the best solution is. I do know that the C programma of our product is the #1 reason potential Users stay away from our product and also the #1 reason they buy our product. Incidentally I don't see Python as being any easier than C for the Users I deal with who feel uncomfortable changing a few lines of code. I don't think a "Master Program" with hundreds of selectable options would be that helpful either because it would be too hard to learn and set all the options and it would be constantly growing with new options.
>
>
>
> BTW we now have a Dynomotion forum on CNCZone and there is one User (Hunter) posting there (he doesn't Yahoo) that has made a VB Form that will create a basic Init.c program from a set of parameters like lead screw pitch, maximum ipm, and such. It is designed for the basic user with a simplified set of options: 3 axes, open loop steppers, optionally one slave, etc... But then I see the first User to consider trying it happens to have encoders, so if we add that in, and then the next option, and the next, it seems to me we will end up with what we already have which is so many options the new user doesn't know where to begin.
>
>
>
> I'm starting to think the best solution is to come up with some standardized form of "Modules". A Module would just be a C function that accepts a list of constant parameters, has a bit of documentation in a standard format describing what the function does and what each parameter is and also a category like "Homing" or "Spindle Control" or "Axis Configuration". These modules could then all be placed in a specific directory where they could be all discovered and placed into a categorized data base. So then a configuration wizard could then query a User with "What type of Homing would you like to do?" and show a list of appropriate Modules such as: Basic, Basic with Encoder, Slaved, Brushless motor with Phase Find, etc... After the User selects the type it would ask the various parameters available: Homing Direction ? Speed? Home Switch IO Bit? etc...
>
>
>
> It seems like for a CNC machine the "types" of modules would be:
>
>
>
> - Axis Configurations
>
> - Homing
>
> - Spindle Control
>
> - Probing
>
> - MPG
>
> - watchdog
>
>
>
> just thinking out loud...sorry for going OT...
>
>
>
> Regards
>
> TK
>
>
>
>
>
> From: brad murry <bradodarb@...>
> To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com>
> Sent: Wednesday, November 23, 2011 9:50 PM
> Subject: RE: [DynoMotion] Re: Mcodes from python
>
>
>
> What you said about the index pulse is functionality I am used to working with as triggers, which would be #5 on my list of "core functions". I'm still hoping to hear you weigh in on this, especially whether it should be all user program space or a mix of c++, perhaps adding to kmotiondll.
>
> -Brad Murry
>
> From: Tom Kerekes
> Sent: 11/23/2011 8:34 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Re: Mcodes from python
>
>
>
> Hi Brad,
>
>
>
> Well there might be cases. Even with a Tool Change if an axis needs to stop on an index pulse for example. We have an M code that captures real time data. Something like a probe or a rigid tap.
>
>
>
> I suppose I'm biased that way because right now all M Codes execute in the board.
>
>
>
> TK
>
>
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, November 23, 2011 6:51 PM
> Subject: [DynoMotion] Re: Mcodes from python
>
>
>
> Brad,
>
> FWIW - Personally, I can't think of any M-codes that require short latency. I would think the only thing that matters is that the script complete execution before the next block is executed. It is very common for M-codes to be implemented in VB in Mach3.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "bradodarb" <bradodarb@> wrote:
> >
> > I'm wiring up the MCode actions in GCodeInterpreter for PCApp callbacks so scripts can be fired off to perform things like toolchanges[M6], etc..
> >
> > A question I have is do any of the mcodes require low latency performance that would only be provided by running directly on the board?
> >
> >
> > I need to do some actual benchmarks, but from testes I've done in the past I think round trip interpretation to execution will be 20-50 ms.
> >
> > I think this will usually be acceptable, but was wondering if I need to provide some of the other Mcode action types.
> >
> > -Brad Murry
> >
>

even better. get it to work like the galil plugin for mach3... thats a work of art and really easy to set up.
the lack of programming c for me is another language id have to learn which is definately holding me off for the moment.

my machine is a very complex 3 axis but with 3 router heads, auto tool change on all 3, 24 vertical drills at different offsets, and a further 10 horizontal drills and just adding a tangental motion head. it also has tool length/diameter and in process tool breakage checking.. and all this run off mach 3.
i managed to program that lot in vb scripting but watching this forum has slowed me in getting my next machine on kflop.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Just my two cents worth.... As Tom basically said, the enormous flexibility the C programmability provides is the KFlops greatest strength, and the fact that you MUST do some C-coding to get even pretty basic functionality working is it's greatest weakness. It's a fabulous product, and quite unique, but it's also quite challenging to bring up. Many potential customers would simply never be able to get the system up and running, beyond perhaps getting basic axis motion, as they would be lost in the C programming. It's OK for the hard stuff to be hard, but the easy stuff MUST be easy, and there's no reason it can't be!
>
> It seems to me this is not fundamentally difficult to overcome for 95+% of users, by providing a few different standardized methods, and just a bit more hand-holding. Looking at how Mach3 handles configuration, and what functionality it provides as standard gives a pretty good model of what functionality is really important. Mach3, right out of the box, meets the needs of probably 98% of its users, with very little fuss. The other 2% (the PITA crowd, like me), are generally smart enough to figure out a way to do the less common functions, and usually make them available to others through the forums.
>
> If it were up to me, I would do the following:
>
> 1) First, improve the documentation, particularly the organization. There's a lot of information there, but it's hard to find what you need, when you need it, and a lot of it is out-of-date (for example, the list of available C functions is missing many, like Jog()). A simple overview of the system, and how it functions would be hugely helpful. (witness how much trouble I've had understanding how to just make the machine move and stop programmatically!)
> 2) Add an "init writer" to KMotion. The current export of individual single-axis C init codes to the clipboard is OK, but it would take so little to just extend it so it writes a complete, working init.c file, it seems silly not to do it. It would seem wise to me to include in this a dialog for setting pin configurations, and writing a header file that defines them all, so they can be used by all user programs.
> 3) Add **a few**, well documented, standardized methods for doing homing, limits, and probing. These would, ideally, be auto-generated, based on input from the user, through a dialog, which specifies which axes, what pins, speeds, sequence of operations, etc. These don't need to be exhaustive, and don't need to cover every conceivable configuration - just the basics would be fine. I would think all of this could be "built-into" the init function, and be triggered by writing command words into persist registers.
> 4) Clean up and document the examples, to clarify the means of providing more complex functionality. There's a lot of duplication in there, and some "cruft" that just confuses us newbies, and the core functionality of some of the examples is really not documented, so that some of them raise almost as many questions than they answer. And the use of hard-coded I/O #s and persist registers makes them really hard to read and understand.
>
> Regards,
> Ray L.
>
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > Fair enough.
> >
> >
> >
> > I can live without most of those items, it was more of a ‘wish list’.
> >
> >
> >
> >
> >
> > The one thing that would be huge is homing, as right now a C program is required to home an axis.
> >
> >
> >
> > Can you provide some sort of functionality for basic homing that does not require this?
> >
> >
> >
> > For complex scenarios a C program can be used and is great but it would nice to do basic edge/index homing.
> >
> >
> >
> >
> >
> > It is for selfish reasons I ask this(it makes it so MM can handle everything), but I have to imagine it would be useful to many people.
> >
> >
> >
> >
> >
> >
> >
> > Thank you,
> >
> >
> >
> > Brad Murry
> >
> >
> >
> >
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > Sent: Friday, November 25, 2011 12:41 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: Re: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> >
> >
> > Hi Brad,
> >
> >
> >
> > Yeah I'm not sure. I'm not saying something like that is not needed but I see some problems. One is that we will be forever having to be in the loop adding new feature requests :} Another is that many of those commands appear to be blocking which would hang all the communication. And if they were made non-blocking they would need an extra cpu thread or extra time in the servo sample code to continuously service them which might make other things less predictable and deterministic.
> >
> >
> >
> > Regards
> >
> > TK
> >
> >
> >
> > From: Brad Murry <bradodarb@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, November 25, 2011 10:04 AM
> > Subject: RE: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> > Asked for a little too much eh?
> >
> >
> >
> > Maybe I can write a home routine writing engine.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Brad Murry
> > Sent: Thursday, November 24, 2011 9:39 AM
> > To: DynoMotion@yahoogroups.com
> > Subject: RE: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> >
> >
> > WOW Tom, thanks for the input.
> >
> >
> >
> > When I suggested KMotionDLL to be added to, I did not mean to use triggering or any other deterministic functions. I was thinking as you said to have some built in functionality(perhaps exposed as script commands) that are also accessible via KMotionDLL.
> >
> >
> >
> > My initial thoughts were that it would be cool to have a master program/mini API (like jquery is for web dev), but I now think it would be cleaner if it existed outside the user program space.
> >
> >
> >
> > Probing, homing and watchdog would be good modules to have available, I think I can handle the rest of your list on the PC side and I already am configuring axes via my GUI/ backed by XML files.
> >
> >
> >
> > If there were a “Master Program” whether as a user program or in conjunction with embedded functions, I was thinking it should be designed to be nearly invisible to the end user. Set some persistent data via some c++ calls, or public members in the .net classes for example.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Python is not my favorite language, I use it only because of the IronPython implementation of it sits atop the DLR, which makes all my .net objects accessible. It’s really close to magic the things you can do dynamically without recompiling source. It just makes for a super flexible application because the GUI stuff can be configured at runtime as well as machine behavior.
> >
> >
> >
> > That said, it is a very human readable language and my technicians can even tweak things without my help. Many video games have this architecture where the heavy lifting(rendering, etc..) is performed by c++ class libraries and things like character behavior are programed in python by higher level developers.
> >
> >
> >
> > I do plan to integrate the Iron JS as soon as it is stable so there are options for scripting in MM. Java Script is closer to C and is a proper ‘braced’ language.
> >
> >
> >
> >
> >
> >
> >
> > So, as a mechanism to facilitate these “core functions” whether by wizards or from a master program can I request some features?
> >
> >
> >
> > 1) Homing
> >
> >
> >
> > Something like _Controller.WriteLine(“HOME<Axis Channel> <Switch BIT> <High/Low> <TYPE>”); would be amazing
> >
> >
> >
> > Homing speed/accel would be nice as additional axis channel members like you already have with MaxVel, etc…
> >
> >
> >
> > TYPE would be negative/positive direction plus the switch logic- (rising falling edge, move to next nearest count, etc…)
> >
> >
> >
> > 2) Polling
> >
> >
> >
> > _Controller.WriteLine(“POLL<BIT><STATE><TIMEOUT>”);
> >
> >
> >
> > 3) IO Pulsing
> >
> >
> >
> > _Controller.WriteLine(“PULSEBIT<BIT><INITIAL STATE><DURATION><PULSES>”);
> >
> >
> >
> > 4) Triggering
> >
> >
> >
> > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><USER THREAD TO EXECUTE>”);
> >
> >
> >
> > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT><STATE>”);
> >
> >
> >
> > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2>”);
> >
> >
> >
> > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2><BIT3><STATE3>”);
> >
> >
> >
> > 5) IO Debounce
> >
> >
> >
> > _Controller.WriteLine(“DEBOUNCEBIT<BIT>”);
> >
> >
> >
> > 6) Recorder
> >
> >
> >
> > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT>”);
> >
> >
> >
> > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT>”);
> >
> >
> >
> > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2>”);
> >
> >
> >
> > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2>”);
> >
> >
> >
> > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2><BIT3>”);
> >
> >
> >
> > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2><BIT3>”);
> >
> >
> >
> > Then
> >
> >
> >
> > _Controller.WriteLine(“RECORDSTOP<AXIS CHANNEL>”);
> >
> >
> >
> > Values could be stored in an array to processed after recording.
> >
> >
> >
> >
> >
> > Ok, so that is quite a request, but I think with the existing script commands and these we would provide all the building blocks needed to rapidly
> >
> > configure a machine with or without user programs.(plus add some additional functionality not necessarily related to configuration but would be great to have).
> >
> >
> >
> >
> >
> > What is involved in exposing functionality such as this via script commands?
> >
> >
> >
> > Thank you for your time,
> >
> > Brad Murry
> >
> >
> >
> >
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > Sent: Thursday, November 24, 2011 4:52 AM
> > To: DynoMotion@yahoogroups.com
> > Subject: Re: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> >
> >
> > Hi Brad,
> >
> >
> >
> > I'm not sure I understand what you mean. As I'm sure you realize anything real time must be performed in the external controller as Windows/The App/KMotionDLL will always have indeterminate response. Windows will be responsive 99.9% of the time but in some very rare cases it will unexpectedly freeze just at the wrong time for a few seconds. I'm fine with that wasting a few seconds now and then, but obviously if it results in missing an index pulse and loading the wrong tool or crashing an axis into the hard stop that is unacceptable. So a "trigger" or interrupt back to the PC doesn't help in those cases. I suppose what you mean is that we could build canned or core functionality into KFLOP to do special operations such as "Stop axis X on Input Bit #N change of Polarity Direction P and signal when complete". So then complex sequences could be programmed on the PC side safely.
> >
> >
> >
> > I don't know what the best solution is. I do know that the C programma of our product is the #1 reason potential Users stay away from our product and also the #1 reason they buy our product. Incidentally I don't see Python as being any easier than C for the Users I deal with who feel uncomfortable changing a few lines of code. I don't think a "Master Program" with hundreds of selectable options would be that helpful either because it would be too hard to learn and set all the options and it would be constantly growing with new options.
> >
> >
> >
> > BTW we now have a Dynomotion forum on CNCZone and there is one User (Hunter) posting there (he doesn't Yahoo) that has made a VB Form that will create a basic Init.c program from a set of parameters like lead screw pitch, maximum ipm, and such. It is designed for the basic user with a simplified set of options: 3 axes, open loop steppers, optionally one slave, etc... But then I see the first User to consider trying it happens to have encoders, so if we add that in, and then the next option, and the next, it seems to me we will end up with what we already have which is so many options the new user doesn't know where to begin.
> >
> >
> >
> > I'm starting to think the best solution is to come up with some standardized form of "Modules". A Module would just be a C function that accepts a list of constant parameters, has a bit of documentation in a standard format describing what the function does and what each parameter is and also a category like "Homing" or "Spindle Control" or "Axis Configuration". These modules could then all be placed in a specific directory where they could be all discovered and placed into a categorized data base. So then a configuration wizard could then query a User with "What type of Homing would you like to do?" and show a list of appropriate Modules such as: Basic, Basic with Encoder, Slaved, Brushless motor with Phase Find, etc... After the User selects the type it would ask the various parameters available: Homing Direction ? Speed? Home Switch IO Bit? etc...
> >
> >
> >
> > It seems like for a CNC machine the "types" of modules would be:
> >
> >
> >
> > - Axis Configurations
> >
> > - Homing
> >
> > - Spindle Control
> >
> > - Probing
> >
> > - MPG
> >
> > - watchdog
> >
> >
> >
> > just thinking out loud...sorry for going OT...
> >
> >
> >
> > Regards
> >
> > TK
> >
> >
> >
> >
> >
> > From: brad murry <bradodarb@>
> > To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com>
> > Sent: Wednesday, November 23, 2011 9:50 PM
> > Subject: RE: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> > What you said about the index pulse is functionality I am used to working with as triggers, which would be #5 on my list of "core functions". I'm still hoping to hear you weigh in on this, especially whether it should be all user program space or a mix of c++, perhaps adding to kmotiondll.
> >
> > -Brad Murry
> >
> > From: Tom Kerekes
> > Sent: 11/23/2011 8:34 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: Re: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> > Hi Brad,
> >
> >
> >
> > Well there might be cases. Even with a Tool Change if an axis needs to stop on an index pulse for example. We have an M code that captures real time data. Something like a probe or a rigid tap.
> >
> >
> >
> > I suppose I'm biased that way because right now all M Codes execute in the board.
> >
> >
> >
> > TK
> >
> >
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Wednesday, November 23, 2011 6:51 PM
> > Subject: [DynoMotion] Re: Mcodes from python
> >
> >
> >
> > Brad,
> >
> > FWIW - Personally, I can't think of any M-codes that require short latency. I would think the only thing that matters is that the script complete execution before the next block is executed. It is very common for M-codes to be implemented in VB in Mach3.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "bradodarb" <bradodarb@> wrote:
> > >
> > > I'm wiring up the MCode actions in GCodeInterpreter for PCApp callbacks so scripts can be fired off to perform things like toolchanges[M6], etc..
> > >
> > > A question I have is do any of the mcodes require low latency performance that would only be provided by running directly on the board?
> > >
> > >
> > > I need to do some actual benchmarks, but from testes I've done in the past I think round trip interpretation to execution will be 20-50 ms.
> > >
> > > I think this will usually be acceptable, but was wondering if I need to provide some of the other Mcode action types.
> > >
> > > -Brad Murry
> > >
> >
>

Well, if you're only interested in running with Mach3, the SmoothStepper is an excellent model - it is absolutely painless to setup, as it uses the exact same configuration as two parallel ports. Never seen the Galil.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "bennyattwell" <brendon@...> wrote:
>
> even better. get it to work like the galil plugin for mach3... thats a work of art and really easy to set up.
> the lack of programming c for me is another language id have to learn which is definately holding me off for the moment.
>
> my machine is a very complex 3 axis but with 3 router heads, auto tool change on all 3, 24 vertical drills at different offsets, and a further 10 horizontal drills and just adding a tangental motion head. it also has tool length/diameter and in process tool breakage checking.. and all this run off mach 3.
> i managed to program that lot in vb scripting but watching this forum has slowed me in getting my next machine on kflop.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Just my two cents worth.... As Tom basically said, the enormous flexibility the C programmability provides is the KFlops greatest strength, and the fact that you MUST do some C-coding to get even pretty basic functionality working is it's greatest weakness. It's a fabulous product, and quite unique, but it's also quite challenging to bring up. Many potential customers would simply never be able to get the system up and running, beyond perhaps getting basic axis motion, as they would be lost in the C programming. It's OK for the hard stuff to be hard, but the easy stuff MUST be easy, and there's no reason it can't be!
> >
> > It seems to me this is not fundamentally difficult to overcome for 95+% of users, by providing a few different standardized methods, and just a bit more hand-holding. Looking at how Mach3 handles configuration, and what functionality it provides as standard gives a pretty good model of what functionality is really important. Mach3, right out of the box, meets the needs of probably 98% of its users, with very little fuss. The other 2% (the PITA crowd, like me), are generally smart enough to figure out a way to do the less common functions, and usually make them available to others through the forums.
> >
> > If it were up to me, I would do the following:
> >
> > 1) First, improve the documentation, particularly the organization. There's a lot of information there, but it's hard to find what you need, when you need it, and a lot of it is out-of-date (for example, the list of available C functions is missing many, like Jog()). A simple overview of the system, and how it functions would be hugely helpful. (witness how much trouble I've had understanding how to just make the machine move and stop programmatically!)
> > 2) Add an "init writer" to KMotion. The current export of individual single-axis C init codes to the clipboard is OK, but it would take so little to just extend it so it writes a complete, working init.c file, it seems silly not to do it. It would seem wise to me to include in this a dialog for setting pin configurations, and writing a header file that defines them all, so they can be used by all user programs.
> > 3) Add **a few**, well documented, standardized methods for doing homing, limits, and probing. These would, ideally, be auto-generated, based on input from the user, through a dialog, which specifies which axes, what pins, speeds, sequence of operations, etc. These don't need to be exhaustive, and don't need to cover every conceivable configuration - just the basics would be fine. I would think all of this could be "built-into" the init function, and be triggered by writing command words into persist registers.
> > 4) Clean up and document the examples, to clarify the means of providing more complex functionality. There's a lot of duplication in there, and some "cruft" that just confuses us newbies, and the core functionality of some of the examples is really not documented, so that some of them raise almost as many questions than they answer. And the use of hard-coded I/O #s and persist registers makes them really hard to read and understand.
> >
> > Regards,
> > Ray L.
> >
> >
> > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > >
> > > Fair enough.
> > >
> > >
> > >
> > > I can live without most of those items, it was more of a ‘wish list’.
> > >
> > >
> > >
> > >
> > >
> > > The one thing that would be huge is homing, as right now a C program is required to home an axis.
> > >
> > >
> > >
> > > Can you provide some sort of functionality for basic homing that does not require this?
> > >
> > >
> > >
> > > For complex scenarios a C program can be used and is great but it would nice to do basic edge/index homing.
> > >
> > >
> > >
> > >
> > >
> > > It is for selfish reasons I ask this(it makes it so MM can handle everything), but I have to imagine it would be useful to many people.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Thank you,
> > >
> > >
> > >
> > > Brad Murry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > Sent: Friday, November 25, 2011 12:41 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > Yeah I'm not sure. I'm not saying something like that is not needed but I see some problems. One is that we will be forever having to be in the loop adding new feature requests :} Another is that many of those commands appear to be blocking which would hang all the communication. And if they were made non-blocking they would need an extra cpu thread or extra time in the servo sample code to continuously service them which might make other things less predictable and deterministic.
> > >
> > >
> > >
> > > Regards
> > >
> > > TK
> > >
> > >
> > >
> > > From: Brad Murry <bradodarb@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, November 25, 2011 10:04 AM
> > > Subject: RE: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > Asked for a little too much eh?
> > >
> > >
> > >
> > > Maybe I can write a home routine writing engine.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Brad Murry
> > > Sent: Thursday, November 24, 2011 9:39 AM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: RE: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > >
> > >
> > > WOW Tom, thanks for the input.
> > >
> > >
> > >
> > > When I suggested KMotionDLL to be added to, I did not mean to use triggering or any other deterministic functions. I was thinking as you said to have some built in functionality(perhaps exposed as script commands) that are also accessible via KMotionDLL.
> > >
> > >
> > >
> > > My initial thoughts were that it would be cool to have a master program/mini API (like jquery is for web dev), but I now think it would be cleaner if it existed outside the user program space.
> > >
> > >
> > >
> > > Probing, homing and watchdog would be good modules to have available, I think I can handle the rest of your list on the PC side and I already am configuring axes via my GUI/ backed by XML files.
> > >
> > >
> > >
> > > If there were a “Master Program” whether as a user program or in conjunction with embedded functions, I was thinking it should be designed to be nearly invisible to the end user. Set some persistent data via some c++ calls, or public members in the .net classes for example.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Python is not my favorite language, I use it only because of the IronPython implementation of it sits atop the DLR, which makes all my .net objects accessible. It’s really close to magic the things you can do dynamically without recompiling source. It just makes for a super flexible application because the GUI stuff can be configured at runtime as well as machine behavior.
> > >
> > >
> > >
> > > That said, it is a very human readable language and my technicians can even tweak things without my help. Many video games have this architecture where the heavy lifting(rendering, etc..) is performed by c++ class libraries and things like character behavior are programed in python by higher level developers.
> > >
> > >
> > >
> > > I do plan to integrate the Iron JS as soon as it is stable so there are options for scripting in MM. Java Script is closer to C and is a proper ‘braced’ language.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > So, as a mechanism to facilitate these “core functions” whether by wizards or from a master program can I request some features?
> > >
> > >
> > >
> > > 1) Homing
> > >
> > >
> > >
> > > Something like _Controller.WriteLine(“HOME<Axis Channel> <Switch BIT> <High/Low> <TYPE>”); would be amazing
> > >
> > >
> > >
> > > Homing speed/accel would be nice as additional axis channel members like you already have with MaxVel, etc…
> > >
> > >
> > >
> > > TYPE would be negative/positive direction plus the switch logic- (rising falling edge, move to next nearest count, etc…)
> > >
> > >
> > >
> > > 2) Polling
> > >
> > >
> > >
> > > _Controller.WriteLine(“POLL<BIT><STATE><TIMEOUT>”);
> > >
> > >
> > >
> > > 3) IO Pulsing
> > >
> > >
> > >
> > > _Controller.WriteLine(“PULSEBIT<BIT><INITIAL STATE><DURATION><PULSES>”);
> > >
> > >
> > >
> > > 4) Triggering
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><USER THREAD TO EXECUTE>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT><STATE>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2><BIT3><STATE3>”);
> > >
> > >
> > >
> > > 5) IO Debounce
> > >
> > >
> > >
> > > _Controller.WriteLine(“DEBOUNCEBIT<BIT>”);
> > >
> > >
> > >
> > > 6) Recorder
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2><BIT3>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2><BIT3>”);
> > >
> > >
> > >
> > > Then
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORDSTOP<AXIS CHANNEL>”);
> > >
> > >
> > >
> > > Values could be stored in an array to processed after recording.
> > >
> > >
> > >
> > >
> > >
> > > Ok, so that is quite a request, but I think with the existing script commands and these we would provide all the building blocks needed to rapidly
> > >
> > > configure a machine with or without user programs.(plus add some additional functionality not necessarily related to configuration but would be great to have).
> > >
> > >
> > >
> > >
> > >
> > > What is involved in exposing functionality such as this via script commands?
> > >
> > >
> > >
> > > Thank you for your time,
> > >
> > > Brad Murry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > Sent: Thursday, November 24, 2011 4:52 AM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > I'm not sure I understand what you mean. As I'm sure you realize anything real time must be performed in the external controller as Windows/The App/KMotionDLL will always have indeterminate response. Windows will be responsive 99.9% of the time but in some very rare cases it will unexpectedly freeze just at the wrong time for a few seconds. I'm fine with that wasting a few seconds now and then, but obviously if it results in missing an index pulse and loading the wrong tool or crashing an axis into the hard stop that is unacceptable. So a "trigger" or interrupt back to the PC doesn't help in those cases. I suppose what you mean is that we could build canned or core functionality into KFLOP to do special operations such as "Stop axis X on Input Bit #N change of Polarity Direction P and signal when complete". So then complex sequences could be programmed on the PC side safely.
> > >
> > >
> > >
> > > I don't know what the best solution is. I do know that the C programma of our product is the #1 reason potential Users stay away from our product and also the #1 reason they buy our product. Incidentally I don't see Python as being any easier than C for the Users I deal with who feel uncomfortable changing a few lines of code. I don't think a "Master Program" with hundreds of selectable options would be that helpful either because it would be too hard to learn and set all the options and it would be constantly growing with new options.
> > >
> > >
> > >
> > > BTW we now have a Dynomotion forum on CNCZone and there is one User (Hunter) posting there (he doesn't Yahoo) that has made a VB Form that will create a basic Init.c program from a set of parameters like lead screw pitch, maximum ipm, and such. It is designed for the basic user with a simplified set of options: 3 axes, open loop steppers, optionally one slave, etc... But then I see the first User to consider trying it happens to have encoders, so if we add that in, and then the next option, and the next, it seems to me we will end up with what we already have which is so many options the new user doesn't know where to begin.
> > >
> > >
> > >
> > > I'm starting to think the best solution is to come up with some standardized form of "Modules". A Module would just be a C function that accepts a list of constant parameters, has a bit of documentation in a standard format describing what the function does and what each parameter is and also a category like "Homing" or "Spindle Control" or "Axis Configuration". These modules could then all be placed in a specific directory where they could be all discovered and placed into a categorized data base. So then a configuration wizard could then query a User with "What type of Homing would you like to do?" and show a list of appropriate Modules such as: Basic, Basic with Encoder, Slaved, Brushless motor with Phase Find, etc... After the User selects the type it would ask the various parameters available: Homing Direction ? Speed? Home Switch IO Bit? etc...
> > >
> > >
> > >
> > > It seems like for a CNC machine the "types" of modules would be:
> > >
> > >
> > >
> > > - Axis Configurations
> > >
> > > - Homing
> > >
> > > - Spindle Control
> > >
> > > - Probing
> > >
> > > - MPG
> > >
> > > - watchdog
> > >
> > >
> > >
> > > just thinking out loud...sorry for going OT...
> > >
> > >
> > >
> > > Regards
> > >
> > > TK
> > >
> > >
> > >
> > >
> > >
> > > From: brad murry <bradodarb@>
> > > To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com>
> > > Sent: Wednesday, November 23, 2011 9:50 PM
> > > Subject: RE: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > What you said about the index pulse is functionality I am used to working with as triggers, which would be #5 on my list of "core functions". I'm still hoping to hear you weigh in on this, especially whether it should be all user program space or a mix of c++, perhaps adding to kmotiondll.
> > >
> > > -Brad Murry
> > >
> > > From: Tom Kerekes
> > > Sent: 11/23/2011 8:34 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > Well there might be cases. Even with a Tool Change if an axis needs to stop on an index pulse for example. We have an M code that captures real time data. Something like a probe or a rigid tap.
> > >
> > >
> > >
> > > I suppose I'm biased that way because right now all M Codes execute in the board.
> > >
> > >
> > >
> > > TK
> > >
> > >
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Wednesday, November 23, 2011 6:51 PM
> > > Subject: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > Brad,
> > >
> > > FWIW - Personally, I can't think of any M-codes that require short latency. I would think the only thing that matters is that the script complete execution before the next block is executed. It is very common for M-codes to be implemented in VB in Mach3.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "bradodarb" <bradodarb@> wrote:
> > > >
> > > > I'm wiring up the MCode actions in GCodeInterpreter for PCApp callbacks so scripts can be fired off to perform things like toolchanges[M6], etc..
> > > >
> > > > A question I have is do any of the mcodes require low latency performance that would only be provided by running directly on the board?
> > > >
> > > >
> > > > I need to do some actual benchmarks, but from testes I've done in the past I think round trip interpretation to execution will be 20-50 ms.
> > > >
> > > > I think this will usually be acceptable, but was wondering if I need to provide some of the other Mcode action types.
> > > >
> > > > -Brad Murry
> > > >
> > >
> >
>

---

From: bennyattwell
Sent: 11/25/2011 3:25 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Re: Mcodes from python

---

From: himykabibble
Sent: 11/25/2011 2:57 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Re: Mcodes from python

brad. this is a quick video of one of my 4 machines.
http://www.youtube.com/watch?v=Ai7mGOdbhns
i was hoping to use the kflop as a cheaper alternative to the galil used on this one. all drilling is handled by one macro with just x y position, depth and tool number required.
video was taken in the early stages of conversion. the machine makes real parts every day

--- In DynoMotion@yahoogroups.com, brad murry <bradodarb@...> wrote:
>
> Benny,
>
> I would love to get MM working on your machine. I will be working with Carl first but maybe after beta ... I have done multiple tc spindles and would he happy to provide tool change scripts.
>
>
>
> -Brad Murry
> ________________________________
> From: bennyattwell
> Sent: 11/25/2011 3:25 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Mcodes from python
>
> even better. get it to work like the galil plugin for mach3... thats a work of art and really easy to set up.
> the lack of programming c for me is another language id have to learn which is definately holding me off for the moment.
>
> my machine is a very complex 3 axis but with 3 router heads, auto tool change on all 3, 24 vertical drills at different offsets, and a further 10 horizontal drills and just adding a tangental motion head. it also has tool length/diameter and in process tool breakage checking.. and all this run off mach 3.
> i managed to program that lot in vb scripting but watching this forum has slowed me in getting my next machine on kflop.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Just my two cents worth.... As Tom basically said, the enormous flexibility the C programmability provides is the KFlops greatest strength, and the fact that you MUST do some C-coding to get even pretty basic functionality working is it's greatest weakness. It's a fabulous product, and quite unique, but it's also quite challenging to bring up. Many potential customers would simply never be able to get the system up and running, beyond perhaps getting basic axis motion, as they would be lost in the C programming. It's OK for the hard stuff to be hard, but the easy stuff MUST be easy, and there's no reason it can't be!
> >
> > It seems to me this is not fundamentally difficult to overcome for 95+% of users, by providing a few different standardized methods, and just a bit more hand-holding. Looking at how Mach3 handles configuration, and what functionality it provides as standard gives a pretty good model of what functionality is really important. Mach3, right out of the box, meets the needs of probably 98% of its users, with very little fuss. The other 2% (the PITA crowd, like me), are generally smart enough to figure out a way to do the less common functions, and usually make them available to others through the forums.
> >
> > If it were up to me, I would do the following:
> >
> > 1) First, improve the documentation, particularly the organization. There's a lot of information there, but it's hard to find what you need, when you need it, and a lot of it is out-of-date (for example, the list of available C functions is missing many, like Jog()). A simple overview of the system, and how it functions would be hugely helpful. (witness how much trouble I've had understanding how to just make the machine move and stop programmatically!)
> > 2) Add an "init writer" to KMotion. The current export of individual single-axis C init codes to the clipboard is OK, but it would take so little to just extend it so it writes a complete, working init.c file, it seems silly not to do it. It would seem wise to me to include in this a dialog for setting pin configurations, and writing a header file that defines them all, so they can be used by all user programs.
> > 3) Add **a few**, well documented, standardized methods for doing homing, limits, and probing. These would, ideally, be auto-generated, based on input from the user, through a dialog, which specifies which axes, what pins, speeds, sequence of operations, etc. These don't need to be exhaustive, and don't need to cover every conceivable configuration - just the basics would be fine. I would think all of this could be "built-into" the init function, and be triggered by writing command words into persist registers.
> > 4) Clean up and document the examples, to clarify the means of providing more complex functionality. There's a lot of duplication in there, and some "cruft" that just confuses us newbies, and the core functionality of some of the examples is really not documented, so that some of them raise almost as many questions than they answer. And the use of hard-coded I/O #s and persist registers makes them really hard to read and understand.
> >
> > Regards,
> > Ray L.
> >
> >
> > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > >
> > > Fair enough.
> > >
> > >
> > >
> > > I can live without most of those items, it was more of a ‘wish list’.
> > >
> > >
> > >
> > >
> > >
> > > The one thing that would be huge is homing, as right now a C program is required to home an axis.
> > >
> > >
> > >
> > > Can you provide some sort of functionality for basic homing that does not require this?
> > >
> > >
> > >
> > > For complex scenarios a C program can be used and is great but it would nice to do basic edge/index homing.
> > >
> > >
> > >
> > >
> > >
> > > It is for selfish reasons I ask this(it makes it so MM can handle everything), but I have to imagine it would be useful to many people.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Thank you,
> > >
> > >
> > >
> > > Brad Murry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > Sent: Friday, November 25, 2011 12:41 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > Yeah I'm not sure. I'm not saying something like that is not needed but I see some problems. One is that we will be forever having to be in the loop adding new feature requests :} Another is that many of those commands appear to be blocking which would hang all the communication. And if they were made non-blocking they would need an extra cpu thread or extra time in the servo sample code to continuously service them which might make other things less predictable and deterministic.
> > >
> > >
> > >
> > > Regards
> > >
> > > TK
> > >
> > >
> > >
> > > From: Brad Murry <bradodarb@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, November 25, 2011 10:04 AM
> > > Subject: RE: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > Asked for a little too much eh?
> > >
> > >
> > >
> > > Maybe I can write a home routine writing engine.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Brad Murry
> > > Sent: Thursday, November 24, 2011 9:39 AM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: RE: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > >
> > >
> > > WOW Tom, thanks for the input.
> > >
> > >
> > >
> > > When I suggested KMotionDLL to be added to, I did not mean to use triggering or any other deterministic functions. I was thinking as you said to have some built in functionality(perhaps exposed as script commands) that are also accessible via KMotionDLL.
> > >
> > >
> > >
> > > My initial thoughts were that it would be cool to have a master program/mini API (like jquery is for web dev), but I now think it would be cleaner if it existed outside the user program space.
> > >
> > >
> > >
> > > Probing, homing and watchdog would be good modules to have available, I think I can handle the rest of your list on the PC side and I already am configuring axes via my GUI/ backed by XML files.
> > >
> > >
> > >
> > > If there were a “Master Program” whether as a user program or in conjunction with embedded functions, I was thinking it should be designed to be nearly invisible to the end user. Set some persistent data via some c++ calls, or public members in the .net classes for example.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Python is not my favorite language, I use it only because of the IronPython implementation of it sits atop the DLR, which makes all my .net objects accessible. It’s really close to magic the things you can do dynamically without recompiling source. It just makes for a super flexible application because the GUI stuff can be configured at runtime as well as machine behavior.
> > >
> > >
> > >
> > > That said, it is a very human readable language and my technicians can even tweak things without my help. Many video games have this architecture where the heavy lifting(rendering, etc..) is performed by c++ class libraries and things like character behavior are programed in python by higher level developers.
> > >
> > >
> > >
> > > I do plan to integrate the Iron JS as soon as it is stable so there are options for scripting in MM. Java Script is closer to C and is a proper ‘braced’ language.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > So, as a mechanism to facilitate these “core functions” whether by wizards or from a master program can I request some features?
> > >
> > >
> > >
> > > 1) Homing
> > >
> > >
> > >
> > > Something like _Controller.WriteLine(“HOME<Axis Channel> <Switch BIT> <High/Low> <TYPE>”); would be amazing
> > >
> > >
> > >
> > > Homing speed/accel would be nice as additional axis channel members like you already have with MaxVel, etc…
> > >
> > >
> > >
> > > TYPE would be negative/positive direction plus the switch logic- (rising falling edge, move to next nearest count, etc…)
> > >
> > >
> > >
> > > 2) Polling
> > >
> > >
> > >
> > > _Controller.WriteLine(“POLL<BIT><STATE><TIMEOUT>”);
> > >
> > >
> > >
> > > 3) IO Pulsing
> > >
> > >
> > >
> > > _Controller.WriteLine(“PULSEBIT<BIT><INITIAL STATE><DURATION><PULSES>”);
> > >
> > >
> > >
> > > 4) Triggering
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><USER THREAD TO EXECUTE>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT><STATE>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“TRIGGER<AXIS CHANNEL><BIT1><STATE1><BIT2><STATE2><BIT3><STATE3>”);
> > >
> > >
> > >
> > > 5) IO Debounce
> > >
> > >
> > >
> > > _Controller.WriteLine(“DEBOUNCEBIT<BIT>”);
> > >
> > >
> > >
> > > 6) Recorder
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><TIMESLICE><BIT1><BIT2><BIT3>”);
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORD<AXIS CHANNEL><COUNT INTERVAL><BIT1><BIT2><BIT3>”);
> > >
> > >
> > >
> > > Then
> > >
> > >
> > >
> > > _Controller.WriteLine(“RECORDSTOP<AXIS CHANNEL>”);
> > >
> > >
> > >
> > > Values could be stored in an array to processed after recording.
> > >
> > >
> > >
> > >
> > >
> > > Ok, so that is quite a request, but I think with the existing script commands and these we would provide all the building blocks needed to rapidly
> > >
> > > configure a machine with or without user programs.(plus add some additional functionality not necessarily related to configuration but would be great to have).
> > >
> > >
> > >
> > >
> > >
> > > What is involved in exposing functionality such as this via script commands?
> > >
> > >
> > >
> > > Thank you for your time,
> > >
> > > Brad Murry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > > Sent: Thursday, November 24, 2011 4:52 AM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > I'm not sure I understand what you mean. As I'm sure you realize anything real time must be performed in the external controller as Windows/The App/KMotionDLL will always have indeterminate response. Windows will be responsive 99.9% of the time but in some very rare cases it will unexpectedly freeze just at the wrong time for a few seconds. I'm fine with that wasting a few seconds now and then, but obviously if it results in missing an index pulse and loading the wrong tool or crashing an axis into the hard stop that is unacceptable. So a "trigger" or interrupt back to the PC doesn't help in those cases. I suppose what you mean is that we could build canned or core functionality into KFLOP to do special operations such as "Stop axis X on Input Bit #N change of Polarity Direction P and signal when complete". So then complex sequences could be programmed on the PC side safely.
> > >
> > >
> > >
> > > I don't know what the best solution is. I do know that the C programma of our product is the #1 reason potential Users stay away from our product and also the #1 reason they buy our product. Incidentally I don't see Python as being any easier than C for the Users I deal with who feel uncomfortable changing a few lines of code. I don't think a "Master Program" with hundreds of selectable options would be that helpful either because it would be too hard to learn and set all the options and it would be constantly growing with new options.
> > >
> > >
> > >
> > > BTW we now have a Dynomotion forum on CNCZone and there is one User (Hunter) posting there (he doesn't Yahoo) that has made a VB Form that will create a basic Init.c program from a set of parameters like lead screw pitch, maximum ipm, and such. It is designed for the basic user with a simplified set of options: 3 axes, open loop steppers, optionally one slave, etc... But then I see the first User to consider trying it happens to have encoders, so if we add that in, and then the next option, and the next, it seems to me we will end up with what we already have which is so many options the new user doesn't know where to begin.
> > >
> > >
> > >
> > > I'm starting to think the best solution is to come up with some standardized form of "Modules". A Module would just be a C function that accepts a list of constant parameters, has a bit of documentation in a standard format describing what the function does and what each parameter is and also a category like "Homing" or "Spindle Control" or "Axis Configuration". These modules could then all be placed in a specific directory where they could be all discovered and placed into a categorized data base. So then a configuration wizard could then query a User with "What type of Homing would you like to do?" and show a list of appropriate Modules such as: Basic, Basic with Encoder, Slaved, Brushless motor with Phase Find, etc... After the User selects the type it would ask the various parameters available: Homing Direction ? Speed? Home Switch IO Bit? etc...
> > >
> > >
> > >
> > > It seems like for a CNC machine the "types" of modules would be:
> > >
> > >
> > >
> > > - Axis Configurations
> > >
> > > - Homing
> > >
> > > - Spindle Control
> > >
> > > - Probing
> > >
> > > - MPG
> > >
> > > - watchdog
> > >
> > >
> > >
> > > just thinking out loud...sorry for going OT...
> > >
> > >
> > >
> > > Regards
> > >
> > > TK
> > >
> > >
> > >
> > >
> > >
> > > From: brad murry <bradodarb@>
> > > To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com>
> > > Sent: Wednesday, November 23, 2011 9:50 PM
> > > Subject: RE: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > What you said about the index pulse is functionality I am used to working with as triggers, which would be #5 on my list of "core functions". I'm still hoping to hear you weigh in on this, especially whether it should be all user program space or a mix of c++, perhaps adding to kmotiondll.
> > >
> > > -Brad Murry
> > >
> > > From: Tom Kerekes
> > > Sent: 11/23/2011 8:34 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: Re: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > Hi Brad,
> > >
> > >
> > >
> > > Well there might be cases. Even with a Tool Change if an axis needs to stop on an index pulse for example. We have an M code that captures real time data. Something like a probe or a rigid tap.
> > >
> > >
> > >
> > > I suppose I'm biased that way because right now all M Codes execute in the board.
> > >
> > >
> > >
> > > TK
> > >
> > >
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Wednesday, November 23, 2011 6:51 PM
> > > Subject: [DynoMotion] Re: Mcodes from python
> > >
> > >
> > >
> > > Brad,
> > >
> > > FWIW - Personally, I can't think of any M-codes that require short latency. I would think the only thing that matters is that the script complete execution before the next block is executed. It is very common for M-codes to be implemented in VB in Mach3.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , "bradodarb" <bradodarb@> wrote:
> > > >
> > > > I'm wiring up the MCode actions in GCodeInterpreter for PCApp callbacks so scripts can be fired off to perform things like toolchanges[M6], etc..
> > > >
> > > > A question I have is do any of the mcodes require low latency performance that would only be provided by running directly on the board?
> > > >
> > > >
> > > > I need to do some actual benchmarks, but from testes I've done in the past I think round trip interpretation to execution will be 20-50 ms.
> > > >
> > > > I think this will usually be acceptable, but was wondering if I need to provide some of the other Mcode action types.
> > > >
> > > > -Brad Murry
> > > >
> > >
> >
>